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Cfasse proposta [sezJcUsdJ) 
L. RIASSUNTO 
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Un procedimento per realizzare, a partire da almeno un oggetto gestore o manager (A) un'attiviti di gestione 
di almeno un oggetto gestito o agent (Bl, BN) tramite almeno una rete telematica (R), comprende le 
operazioni di: 

- prowedere almeno un oggetto intermedio o agent gerarchico (AG) configurato per realizzare su 
detto almeno un oggetto gestito (Bl, BN) la suddetta attivit& di gestione in fimzione di un insieme di 
informazioni (1 100), PattivM di gestione traducendosi in un insieme di risultati (1 104), 

- fornire il suddetto insieme di informazioni (1 100) a partire dall'oggetto gestore (A) verso l'oggetto 
intermedio (AG), 

- svolgere Tattiviti di gestione di detto almeno un oggetto gestito (Bl, BN) tramite l'oggetto 
intermedio (AG), cosl da generare il suddetto insieme di risultati (1 104), e 

- trasferire (1108) Tinsieme di risultati (1104) cosi ottenuti dall'oggetto intermedio (AG) verso 
l'oggetto gestore (A). 

Di preferenza, la comunicazione fra oggetto gestore (A) ed oggetto intermedio (AG) si realizza 
tramite protocollo UDP e secondo modalita compresse. 
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DESCRIZIONE dell ' invenzione industriale dal titolo: 
"Procedimento per organizzare la comunicazione fra 
oggetti gestori ed oggetti gestiti in una rete 
telematica, relativa architettura e prodotto 
informatico" 

di: Telecom Italia Lab S.p.A., nazionalita italiana, 
Via G. Reiss Romoli, 2 74 - Torino 
Invent ore designator Mauri zio GIRARDI 

Depositata il : 12 aprile 2002 |@ 2002AQ00325 
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TESTO DELLA DESCRIZIO NE °« ^5 

— : og 

La presente invenzione si rif erisce alle 
tecniche che consentono, nell'ambito di una rete Q rr! ^ 

telematica, la comunicazione fra almeno un oggetto mO 
/ 4 gestore (nel seguito denominato per brevita « < 

"manager") ed almeno un oggetto gestito (nel seguito 
indicato per brevita come "agent") . 

Una tipica architettura di riferimento 
utilizzata a tal fine e quella rappresentata nella 
figura 1 dove e raffigurato il collegamento fra un 
modulo manager A ed un certo numero di elementi di 
tipo agent Bl, B2 , B3 , ... interconnessi attraverso 
una rete di telecomunicazioni R. 

Tale architettura e quella prevista, ad esempio, 
dalle specifiche del protocollo denominato SNMP, 
acronimo per Simple Network Management Protocol . Al 
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riguardo si pud utilmente consultare il documento 
RFC1157, revisione 1990. 

A livello di inquadramento generale, 
1'architettura dei protocolli internet § basata su 
quattro livelli logici, denominati correntemente con 
terminologia anglosassone : Application (A), 
Transport (T) , Network (N) e Link (L) . 

Si osservi al riguardo la rappresentazione della 

figura 2, dove si vede che ogni livello e di fatto 

incapsulato dai protocolli sottostanti. Ad esempio, 

i protocolli a livello Application, quali ad esempio ^ >< 

i protocolli SNMP e TFTP gia citati in precedenza, ^ P 

< Q 

owero i protocolli denominati Telnet o FTP O zd ~ 

Z UJ ^ 

risultano incapsulati dai protocolli sottostanti. 

In particolare, i protocolli SNMP e TFTP sono 2< 



incapsulati nel protocollo UDP (User Datagram 
Protocol) che, a sua volta, e innestato nel 
protocollo IP (Internet Protocol) e quindi, 
attraverso driver software o dispositivi hardware, 
iniettato nel dispositivo fisico di trasporto (cavo, 
fibra, onde radio) indicato con il riferimento D e 
tale da realizzare a livello fisico il livello Link 
L. 

In modo analogo, i protocolli Telnet e TFTP sono 
incapsulati nel protocollo TCP (Transmission Control 
Protocol) che, a sua volta, e innestato nel 
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protocollo IP e quindi iniettato nel dispositivo 
fisico di trasporto L. 

Le caratteristiche principali dei protocolli TCP 
e UDP del livello di trasporto possono essere 
sintetizzati nei termini seguenti. 

II protocollo TCP d un protocollo orientato alia 

comunicazione tra sistemi (questi ultimi sono 

identificati attraverso un indirizzo di rete) ed e 

legato al software che lo utilizza. Prima di 

effettuare una comunicazione utilizzando questo 

protocollo, e necessario instaurare una connessione, x 

o ^ 

vale a dire una comunicazione permanente con il P 

£° 

sxstema remoto. Il trasf erimento dei dati e O 5 ~* 

controllato e garantito, ma lento, soprattutto per 

M i — 

comunicazioni discontinue o di piccola entita. Il ^< 
ritardo e causato sia dalle caratteristiche del 
protocollo IP, sia dal fatto che la connessione 
viene creata ad ogni richiesta e rimossa, al termine 
della comunicazione, owero chiusa, se non 
utilizzata. La comunicazione e dispendiosa in 
termine di risorse di sistema utilizzate a causa 
della complessita del protocollo e dei controlli a 
cui i dati e la connessione sono soggetti al fine di 
garantire la correttezza della comunicazione. 

Al contrario, il protocollo UDP e orientato alia 
comunicazione fra processi, identificati attraverso 



porte logiche carat terizzate da un numero compreso 
fra 0 a 65535. In trasmissione, il protocollo 
accetta i messaggi provenienti da diversi processi 
applicativi passandoli a protocolli IP per il 
trasporto. Questa funzionalitd, e chiamata 
multiplexing. In ricezione, il protocollo UDP riceve 
i pacchetti dati dallo strato IP inoltrandogli un 
processo applicativo di destinazione . Questa 
funzionalita e denominata de -multiplexing . 

II protocollo UDP risulta molto leggero dal 
punto di vista dell ' utilizzo delle risorse ed e 
semplice da realizzare e gestire. In particolare, 
esso ha un header (denominato "PDU User Header") 
sintetico di sessantaquattro bit suddivisi in 
Source port" , "destination port", "length" e "check 
sum" , nonche un ulteriore header di novantadue bit 
composto dai campi "source address" , "destination 
address", "filler", "protocol type", "length PDU" . 

II protocollo UDP e veloce, in guanto il 
protocollo di trasporto IP non deve effettuare 
elaborazioni o controlli, ma semplicemente 
trasportarlo, se possibile, dall ' indirizzo di rete 
corrente a quello di destinazione. 

In modo nativo, il protocollo UDP non utilizza 
messaggi di controllo di verifica dell'awenuta 
ricezione (acknowledge) , non ordina i messaggi, non 



fornisce il controllo di flusso e quindi non e 
completamente sicuro ed affidabile, nel senso che i 
messaggi in rete possono essere persi o scartati, 
duplicati, ricevuti non in sequenza oppure avere una 
velocita di arrivo superiore a quella del processo 
applicativo e ricevente. 

Una generica architettura di processi che 
utilizzano UDP come protocollo di trasporto ha come 
caratteristica quella di essere associata ad una 
porta secondo i criteri schematicamente illustrati 
nella figura 3. 

Esistono due criteri di fondo per assegnare i 
numeri relativi alle porte di ricezione e di 
trasmissione . 

Un primo criterio e quello di realizzare 
un'assegnazione di tipo universale (universal 
assignment) , in cui i suddetti numeri relativi 
vengono definiti uf f icialmente e riconosciuti da 
tutti • 

Un secondo criterio prevede un legame di tipo 
dinamico "dynamic binding" : ogni volta che un 
programma ha bisogno di una porta, la richiede e 
questa gli viene assegnata dal software di rete. Le 
porte di ricezione sono normalmente pre-assegnate, 
anche se possono essere modificate. Le porte di 



trasmissione possono essere definite utilizzando 
indif f erentemente uno dei due metodi . 

In particolare, nello schema della figura 3, il 
riferimento PA indica collettivamente diversi 
processi applicativi (1, 2, 3 . che dialogano con 
il protocollo UDP attraverso tre rispettive porte. 

In maggior dettaglio e facendo riferimento alio 

schema della figura 4, nelle architetture di 

gestione basate sul protocollo UDP e possibile 

identif icare, oltre ai processi applicativi, 

ulteriori componenti interagenti denominati "oggetti °3 ^5 

fisici" e "componenti logici" . ^ 

£ f __. 

Per quanto riguarda i processi applicativi d poi ^ j=j £ 

possibile distinguere (in funzione del ruolo al n3 0 

M I — 

moment o svolto) , un processo applicativo ^ < 

originatore, dunque con funzione di manager, 
genericamente indicato con A, e uno (o piu) processi 
applicativi destinatari (denominati agent) . 

La denominazione oggetto fisico e riservata ai 
contenitori o support! hardware (ad esempio un 
personal computer) nel quale sono ospitati altri 
oggetti fisici necessari al funzionamento delle 
applicazioni . I suddetti contenitori sono 
identificati nello schema della figura 4 con i 
riferimenti Pi e P 2 . Ulteriori oggetti fisici sono 
costituiti da una memoria di esecuzione fisica (ad 
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esempio una RAM) e/o virtuale (su file) e dall'unita 
di elaborazione (CPU) utiizzata dal supporto o dai 
supporti hardware per l'esecuzione dei processi 
(software, firmware di base, protocolli, 
applicazioni) . Nello schema della figura 4 i 
rif erimenti R x e R 2 indicano appunto memorie di 
questo tipo. 

Nello stesso schema della figura 4, il 
riferimento W indica il software di sistema a 
livello di sistema operative mentre invece i 
rif erimenti Y e Z identif icano il software composto O o 

da uno o piu protocolli orientato al software 
applicativo (transport) ed il software (in questo 



alia scheda di rete o trasduttore CR destinato a 
consent ire il dialogo con la rete R. 

Osservando lo schema della figura 4, che 
illustra le relazioni fra processi applicativi, 
oggetti e componenti dell'architettura, si possono 
fare le seguenti osservazioni . In un sistema o 
dispositivo esiste un software di sistema W che 
consente 1 ' espletamento dei compiti assegnati 
utilizzando una porzione della memoria di esecuzione 
Ri, R 2 disponibile. 

Un processo A residente nel sistema P x comunica 
con un processo B residente nel sistema P 2 , 



3o 



O ri~ 

M O 

caso composto da uno o piu protocolli) orientato 3^ 
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attraverso i componenti SW, Y e Z presenti 
necessariamente in entrambi i dispositivi, le schede 
di rete ed il supporto fisico. 

I componenti software A, B, Y, Z e W utilizzano 
per il loro funzionamento, condividendola, una certa 
quant ita delle memorie R X/ R 2 in funzione delle loro 
caratteristiche . 

La banda massima utilizzabile e legata alle 
caratteristiche della rete R e delle schede di rete 
CR, che devono necessariamente coincidere . 

Le possibility di impiego di un'architettura del 
tipo di quella rappresentata nella figura 1 sono 
condizionate da una serie di f attori . 

In primo luogo, la banda massima utilizzabile 
sulla rete R e condizionata dal numero di manager e 
di agent presenti e dalla quantita di traffico da 
questi generata . La banda utilizzabile pud essere 
massima solo nel caso in cui siano presenti solo due 
dispositivi, ossia un manager ed un agent. Nel caso 
in cui vi sia un solo dispositivo manager e piu 
dispositivi agent, la banda utilizzabile deve essere 
necessariamente condivisa. Da cio consegue il fatto 
che la banda massima utilizzabile per ogni 
comunicazione fra il manager e gli agent non pud 
essere garantita. 



In generale, la comunicazione fra manager e piu 
agent pud essere gestita tanto con una strategia di 
tipo sequenziale, quanto con una strategia in 
parallelo. 

La strategia sequenziale prevede che il manager 
effettui una comunicazione con un agent e attenda 
che questa sia conclusa prima di proseguire con le 
comunicazioni successive . 

La strategia in parallelo sfrutta la 
funzionalita di multiplexing e de -multiplexing ^ >< 

of f erta dal protocollo utilizzato (si pud trattare O o 

tipxcamente di un protocollo UDP, acronimo per User 



Datagram Protocol) attraverso un meccanismo' di 
concorrenza nella locazione dinamica delle porte per 
instaurare un certo numero di comunicazioni 
contemporanee con piu agent . 

Adottando la modality sequenziale, tanto la 
banda utilizzata in uscita dal manager verso gli 
agent (ossia la somma delle dimension! total i dei 
messaggi inviati, divisa per il tempo necessario ad 
inviarli) , quanto la banda in ingresso al manager 
(ossia la somma delle dimensioni totali dei messaggi 
ricevuti dal manager da ogni nodo, diviso per la 
somma del tempo impiegato dal manager per riceverli, 
il tempo di ricezione essendo la somma del tempo di 
elaborazione dell 'agent piu il ritardo imposto dalla 



nj O 

M I — 

2? 
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rete) sono entrambe basse, in quanto i tempi di 
invio e ricezione sono lunghi . 

Utilizzando la modalita in parallelo, la banda 
utilizzata in uscita dal manager verso gli agent e 
alta e la banda in ingresso pud essere anche 
altissima, sia perche i tempi di invio e di 
ricezione sono molto brevi, sia perche le dimensioni 
delle risposte sono sicuramente superiori a quelle 
richieste . 

L' architettura secondo la tecnica nota 
rappresentata nella figura 1 presenta tuttavia 
numerose limitazioni ed inconvenient i . 

La trasmissione sequenziale non e efficace se il 
numero di agent cresce oltre un certo valore (ad 
esempio un migliaio di oggetti) . Questo in quanto i 
tempi necessari al completamento delle attivita 
aumentano sensibilmente . Inoltre , 1 ' architettura 
della figura 1 genera picchi di traffico (burst) , 
anche di dimensioni elevate, dovuti al fatto che sia 
il traffico generato dalle richieste simultanee 
effettuate dal manager, sia il traffico di ritorno 
generato dagli agent possono manifestarsi in modo 
contemporaneo . Tale comportamento pud superare i 
limiti di banda disponibile, con conseguente degrado 
delle funzionalita della rete e perdita di 
messaggio. 
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La modality di funzionamento in paralleled 
utilizza piu processi di tipo manager 
contemporaneamente allocati su porte UDP diverse, e 
questo pu6 portare ad un esaurimento delle risorse 
di si sterna come RAM e CPU. 

I protocolli utilizzati dai processi 

applicativi, ad esempio il protocollo SNMP gia 

citato in precedenza o il protocollo TFTP (acronimo 

per Trivia File Transfer Protocol, si veda al 

riguardo il documento RFC1350) non sono ottimizzati 

per il trasporto di grosse quantita di informazioni Q g 

o per reti con un numero elevato di agent. In piu, i ;< ^ 

O ri "72 

protocolli utilizzati sono del tipo punto-punto, per ^ 
cui non e possibile realizzare e gestire nk 
architetture multi-livello . 

Ancora, nell ' architettura della figura 1 § 
previsto che tutti gli agent debbano essere, in 
qualche modo, direttamente raggiungibili dal 
manager. Gli agent non raggiungibili direttamente 
dal manager, ad esempio perche connessi a reti 
diverse da quella del manager stesso, richiedono, 
per la loro gestione, 1 ' installazione di un manager 
dedicate . 

La presente invenzione si prefigge lo scopo di 
fornire una soluzione in grado di superare i 
suddetti inconvenient i . 



CO 
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Secondo la presente invenzione, tale scopo vlene 

raggiunto grazie ad un procedimento avente le 

caratteristiche richiamate in modo specifico nelle 

rivendicazioni che seguono. L' invenzione riguarda 

anche la corrispondente architettura di rete nonche 

il corrispondente prodotto informatico, vale a dire 

il prodotto informatico direttamente caricabile 

nella memoria di un elaboratore digitale e 

comprendente porzioni di codice software 

suscettibili di attuare il procedimento secondo 

1' invenzione guando il prodotto informatico viene ^ x 

eseguito su un elaboratore digitale. Oq 

< o 



In sostanza, la soluzione secondo I 7 invenzione 
mira a realizzare un' architettura di gestione 



O r!~ 

z: *> 

M O 
M I — 

ottimizzata multilivello tale da rendere possibile ^ Z 

la suddivisione dell ' attivita di gestione su piu 
macchine, superando la limitazione legata 
all'esigenza di utilizzare un' architettura 

tradizionale mono-livello . Tutto questo limitando 
l'utilizzazione della banda in particolare per 
quanto riguarda la possibility di ottimizzare 

l'utilizzazione delle risorse fisiche del manager. J 

In sintesi, la soluzione secondo 1 'invenzione /^^IS^^M 
prevede la realizzazione di un oggetto intermedio,M©' ffM 
ossia una nuova tipologia di agent, denominato^ • ^ti 



*agente o agent gerarchico" , xn grado di ricevere '" " 
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dal manager sufficienti informazioni per effettuare 
le stesse attivita di gestione che il manager 
avrebbe il compito di effettuare lui stesso in modo 
diretto sugli agent controllati. 

Cosi come meglio descritto nel seguito, la 
soluzione secondo l'invenzione si presta ad essere 
utilizzata in modo particolarmente vantaggioso in 
unione a tecniche per il trasf erimento di messaggi 
su UDP con modalita compresse . 

L'invenzione verra ora descritta, a puro titolo o# >< 

di esempio non limitativo, con riferimento ai a* P 

£ - 

disegni, nei quali: O 

z yd 

- le Figure 1 a 4, relative alia tecnica nota, — 
sono gia state descritte in precedenza, ^ ^ 

- la Figura 5 illustra, in termini generali, la 
nuova architettura di gestione proposta secondo 
1 ' invenzione, 

la Figura 6 illustra una prima forma di 
attuazione della soluzione secondo l'invenzione, 

la Figura 7 illustra una seconda forma di 
attuazione della soluzione secondo l'invenzione, 

- la Figura 8 fornisce un esempio di logica 
operativa di architettura secondo l'invenzione, 

- la Figura 9 illustra un possibile schema di 
gestione delle comunicazioni in seno ad 
un' architettura secondo l'invenzione, 
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- la Figura 10 illustra la gestione di un agent 
secondo modalita di condivisione, 

- la Figura 11 illustra 1 ' architettura di un 
cosiddetto agente gerarchico secondo 1 ' invenzione, 

la Figura 12 illustra una possibile 
organizzazione della struttura e dell ' incapsulamento 
dei comandi supportati da un agente gerarchico 
nell'ambito della presente invenzione, 

- le Figure 13 a 15, ciascuna suddivisa in due 

parti, rispettivamente relative alia trasmissione 

(parte a) ed alia ricezione (parte b) , illustrano °° =f 

O o 

sotto forma di diagrammi di f lusso alcune forme di < Q 

f— . 

attuazione preferite della soluzione secondo § Ej 5 

1 ' invenzione , fsf O 

M i— 

- la Figura 16 e un'ulteriore diagramma di 00 < 
flusso illustrativo delle caratteristiche piu 
generali della soluzione secondo 1 ' invenzione, e 

- le Figure 17 e 18 illustrano ulteriori criteri 
di possibile realizzazione della soluzione secondo 
1' invenzione, illustrata in due possibili varianti. 

Lo schema della figura 5 riproduce lo schema 
generale di un' architettura secondo 1 ' invenzione . 

Per diretto confronto con lo schema della figura 
1 e possibile notare che, secondo 1 ' invenzione, 
1' architettura basata sulla presenza di un manager A 
e di una plurality di agent Bl, B2, B3 che dialogano 
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fra loro d stata integrata prevedendo la presenza di 
un modulo ulteriore, ossia di un oggetto intermedio 
denominato agent gerarchico AG. 

In sostanza, 1 ' agent gerarchico AG dialoga con 
il manager A in modo da ricevere dal manager A 
stesso sufficienti informazioni per effettuare, nei 
confronti di un certo numero di agent Bl, B2 , B3 (il 
numero di questi agent pud essere naturalmente 
qualsiasi) , le stesse attivita di gestione che il 
manager A ef f ettuerebbe su tali agent. 

II ricorso alia soluzione secondo 1 ' invenzione 
non esclude il fatto che il manager A conservi e 
continui a svolgere l'attivita di controllo diretta 
su altri agent, indicati con i riferimenti Bk, 
BN nello schema della figura 5. 

E' evidente che tanto il numero di agent Bl, 
BN present i, quanto la loro ripartizione, ai 
fini della gestione, fra agent gerarchico AG e 
manager A pud essere qualsiasi. 

L'architettura schematicamente rappresentata 
nella figura 5 consente di realizzare architetture 
multi-livello senza duplicare le funzionalita del 
manager, dal momento che consente di utilizzare un 
nuovo elemento (appunto 1' agent gerarchico AG) in 
grado di effettuare l'attivita richiesta restituendo 
i risultati ottenuti. 
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In pratica, 1'oggetto intermedio denominate* 
agent gerarchico AG d in grado di ricevere dal 
manager A, presentandosi come agent (Bl, B2 , B3 , 
. .-), messaggi opportunamente formattati, ad esempio 
messaggi SNMP, contenenti informazioni sufficienti 
ad effettuare le attivita richieste dal manager A su 
specifici agent identif icabili da un indirizzo di 
rete utilizzando specifici protocolli (SNMP, TFTP, 
Telnet, DNS, ecc). Terminate le attivita richieste, 
il modulo AG restituisce al manager A il loro esito. 
L'interconnessione fra manager A e agent gerarchico 
AG pud essere realizzata utilizzando la stessa rete 
R (cosi come awiene nella prima forma di attuazione 
rappresentata nella figura 6) oppure attraverso reti 
diverse utilizzando una doppia connessione di rete 
(cosi come awiene nella forma di attuazione 
illustrata nella figura 7, dove i riferimenti RP e 
RA indicano appunto le due reti in questione) . 

Lo schema della figura 7 evidenzia 1'estrema 
flessibilita della soluzione secondo I'invenzione. 

In particolare, in tale schema si vede come la 
prima rete, indicata con RP, pud essere utilizzata 
tanto per le comunicazioni fra manager A ed un agent 
Bl che continua ad essere gestito direttamente dal 
manager A, quanto per consentire le comunicazioni 
fra manager A e 1' agent gerarchico AG che 
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"sostituisce" il manager A nella gestione ciegli 
agent B2 e B3 operando su una seconda rete indicata 
con RA. 

La soluzione secondo l'invenzione consente anche 
di ottimizzare l'utilizzo della rete (o delle reti, 
in generale) in termini di banda. 

In particolare, al fine di ridurre il . traf f ico 
sulla rete dovuto alia comunicazione fra manager A 
ed agent gerarchico AG viene utilizzata di 
preferenza una tecnica di compressione algoritmica 
delle informazioni contenute nei protocolli °^ 
applicativi (OID in SNMP, carico utile o payload in <C & 

UDP, ecc.) . Q 



zty « 



Questa tecnica prevede essenzialmente di £j 2 

sottoporre (almeno) il carico utile del messaggio ad < 
un'operazione di compressione basata di preferenza 
sul riconoscimento di sequenze che compaiono 
periodicamente nel messaggio. In modo 

particolarmente preferito, tale operazione di 
compressione viene svolta secondo una tecnica di 
tipo gzip quale zLib. 

Questa tecnica, su cui si ritornera in maggior 
dettaglio con riferimento alle figure 12 e 
successive, consente di ridurre il numero di 
pacchetti dati PDU scambiati a favore di un piu 
elevato contenuto informative 



-ia- 



\ 



A titolo di esempio, una PDU dati del protocollo 
TFTP utilizza 516 byte e quindi il trasf erimento di 
un file di 520 Kb richiede 1016 pacchetti. 
Sottoposti a compressione secondo i criteri sopra 
richiamati, 52 0 Kb diventano 4 Kb, per cui risulta 
possibile trasportarli con un solo pacchetto dati 
UDP o in un messaggio SNMP. II trasf erimento 
consiste quindi nel trasporto di "messaggi 
applicativi equivalent i" invece di "singoli 
messaggi" . E' cosi possibile ridurre la quantita di w 
traf f ico generato a parita di inf ormazioni O o 

trasf erite. _ . 

O rf — 

La soluzione illustrata consente altresi di J2. 

m O 

ottimizzare le risorse di sistema necessarie alio p z 

svolgimento della attivit^. 

La soluzione illustrata consente infatti di 
distribuire le attivita del manager su piu agenti 
gerarchici AG operando ad esempio secondo i criteri 
dello schema della figura 10. In tale figura i 
riferimenti AG1 e AG2 indicano due agent gerarchici 
che cooperano con un manager A nella gestione di un 
certo numero di agent Bl a B5, essendo altresi 
prevista la possibility che uno o piu agent (1' agent 
B3, nell' esempio illustrato) venga gestito in modo 
condiviso dai due agent gerarchici AG1 e AG2 . 



< 



La possibility di distribuire 1' attivita del 
manager A su piu agent gerarchici consente di 
utilizzare le risorse (CPU, RAM, ecc.) libere al 
momento. II traffico di ritorno verso il manager A - 
prodotto solo al termine delle attivita - dagli 
agent gerarchici AG1 e AG2 e costituito dai soli 
risultati ottenuti, trasferiti dagli agent 
gerarchici AG1 ed AG 2 al manager A. Tut to questo 
awiene di preferenza secondo modalita compresse, 
dunque ricorrendo a pochi pacchetti di dimensioni 
medio-piccole e con elevato contenuto informative 
Questi pacchetti non inficiano le risorse del 
sistema del manager A necessarie per la loro 
decompressione e gestione. 

Cosi come meglio illustrato nello schema della 
figura 8, 1 ' interazione fra manager A e agent 
gerarchico AG (nel seguito si fara riferimento per 
semplicit& alia presenza di un solo modulo di questo 
tipo, ma l'estensione al caso in cui siano presenti 
piu moduli di agent gerarchico £ del tutto evidente) 
si basa sullo svolgimento di macroattivita e sullo 
scambio di segnalazioni utili alia gestione. 

In particolare, in un passo indicato con 1100, 
il manager A invia all 'agent gerarchico AG una 
richiesta di attivita sotto forma di messaggi, ad 
esempio utilizzando un messaggio SNMP standard o 



compresso. In un passo indicato con 1102, 1' agent 
gerarchico AG riceve la richiesta e la analizza, 
iniziando 1 ' esecuzione e la raccolta delle 
informazioni . Durante 1' esecuzione - passo 1104 - 
1' agent gerarchico AG invia al manager A messaggi 
statistici e di sincronizzazione sullo stato delle 
attivita in corso: cio awiene in un passo indicato 
con 1106. Terminata 1' esecuzione dell ' attivita di 
gestione degli oggetti gestiti, ossia degli agent, 
l'agente gerarchico AG invia i risultati al manager 
A. Cio awiene in un passo indicato con 1108. In un 
passo indicato con 1110 il manager A riceve ed 
elabora i risultati dell ' attivita, inviando 
all 'agent gerarchico, in un passo 1112, un messaggio 
di riscontro che conferma la ricezione dei 
risultati. L' agent gerarchico AG conclude quindi 
1' attivita richiesta in un passo indicato con 1114. 

II ciclo appena descritto pud essere reiterato 
piu volte dal manager in funzione del risultato 
ottenuto. Ad esempio, se alcune informazioni non 
vengono considerate sufficienti, vengono effettuate 
nuove richieste. 

II diagramma della figura 9 descrive gli 
elementi logici di alto livello dell 'agent 
gerarchico AG e le relazioni con le altre componenti 
dell ' architettura . 
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Si apprezzera che lo schema della figura 9 
corrisponde essenzialmente all' architettura della 
figura 5, dove <§ previsto che il manager A conservi 
la funzione di gestione diretta di alcuni agent Bk, 
. . . , BN 7 demandando invece la gestione di altri 
agent Bl, B2 e B3 all 'agent gerarchico AG. Per 
quanto riguarda 1 ' interf acciamento alia rete R lo 
schema e quello della figura 6. 

II manager A dialoga con gli agent di sua 
competenza diretta e con 1' agent gerarchico AG 
utilizzando una comunicazione basata su protocollo 
UDP, ad esempio utilizzando messaggi SNMP standard, 
o - in modo preferito - compressi. 

A tale fine, nell'ambito dell 'agent gerarchico 
AG, oltre ad una logica di controllo e gestione LCG 
sono previsti due moduli indicati rispettivamente 
ARX e ATX destinati a gestire le comunicazioni fra 
1' agent gerarchico AG ed il manager A in modo tale 
per cui 1' agent gerarchico AG e "visto" dal manager 
A essenzialmente come se si trattasse di un altro 
agent gestito direttamente dal manager A. 

Nell'ambito dell 'agent gerarchico AG e poi 
presente un modulo denominate multi -manager MM che 
sovraintende alle comunicazioni fra 1' agent 
gerarchico AG e gli agenti Bl, B2 , B3 in modo tale 
per cui questi ultimi agent menzionati "vedono" 
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1' agent gerarchico AG sostanzialmente come se si 
trattasse del manager A. 

II manager A e la componente multi -manager 
dell 'agent gerarchico AG comunicano con i vari agent 
utilizzando metodologie/protocolli standard. 

Da cio consegue la possibility, illustrata nello 
schema della figura 10, di far si che uno stesso 
agent (nel caso dell'esempio illustrato, si tratta 
dell 'agent B3) possa essere gestito da uno o piu 
agent gerarchici AG1 o AG2 pilotati da uno stesso 
manager . 

Lo schema della figura 11 illustra 
1' architettura interna dell ' agent gerarchico AG con 
la quale si realizza la relativa logica di gestione 
e controllo. 

In modo preferito la soluzione in questione si 
basa sulla compressione del messaggio completo 
(header indicato con MH, e PDU) . 

Sono in particolare previste due possibili 
diverse modalita di trasf erimento . La prima 
incapsula il messaggio SNMP in un nuovo messaggio 
SNMP di tipo compresso e lo invia in modalita 
standard utilizzando UDP. La seconda pilota 
direttamente UDP attraverso un driver fornendo come 
contenuto dati (Data Octet) il risultato della 
compressione del messaggio SNMP. 
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La tecnica di compressione si basa 

essenzialmente sul riconoscimento di sequenze che 

compaiono periodicamente nel messaggio. 

In una forma di attuazione particolarmente 

preferita, quale tecnica di compressione viene 

utilizzata una variante della tecnica nota come LZ77 

(si veda al riguardo il lavoro di Ziv. J. , Lempel 

A., W A Universal Algorithm for Sequential Data 

Compression" , IEEE Transactions on Information 

Theory, Vol. 23, No. 3, pp. 337-343) ben conosciuta 

in ambiente UNIX e denominata gzip (gzip format - O o 

RFC 1952) utilizzata anche dal piu popolare PKZIP. _ 

Or! L 

Le specif iche di tale tecnica sono di pubblico \M " 

. . NO 
dominio e sono altresi disponibili librerie sorgenti ^ £ 

CO 

che implementano ed utilizzano questa soluzione per 
diversi ambienti di sviluppo e sistemi operativi 
come HP-UX, Digital, BeOS, Linux, OS/2, Java, Win32, 
WinCE . 

In particolare e possibile utilizzare un porting 
dell' algoritmo su Win32 utilizzando la libreria 
u zLib" . La caratteristica principale di questa 
libreria d quella di consentire la compressione 
runtime e on-memory sia di strutture dati binarie, 
sia di stringhe, fattore importante per le 
prestazioni del sistema. 
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Nello schema della figura 11 sono in primo luogo 
rappresentati i moduli ARX ed ATX gia citati con 
riferimento alia figura 9. 

II modulo ARX si occupa esclusivamente della 
raccolta dei messaggi provenienti dalla rete R, 
passandoli ad una coda di ingresso I prevista in un 
modulo di gestione delle code indicato con G. 

In modo simmetrico, il modulo ATX si occupa 
esclusivamente dell'invio dei messaggi provenienti 
dalla coda di uscita, indicata con U, del gestore 
delle code G. 

II modulo G si occupa esclusivamente di 
analizzare, ad ogni impulso di clock, i messaggi 
presenti dalle code di ingresso I, di uscita U ed in 
un'ulteriore coda, denominata coda di lavoro, 
indicata con L . 

II suddetto segnale di clock viene generato da 
un modulo indicate con T, che si occupa 
esclusivamente di generare il clock di 
sincronizzazione del gestore delle code G. 

Ad ogni clock generato dal timer T, i messaggi 
che si trovano nella coda di ingresso I vengono 
prelevati ed inoltrati ad un modulo DC fungente da 
modulo interpret atore (ed in modo preferito, anche 
da modulo decompressore) dei messaggi per la 
successiva elaborazione . II suddetto modulo 
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decompressore/interpretatore e indicato con il 
rif erimento DC. 

Inoltre, ad ogni clock generato dal timer T, i 
messaggi presenti nella coda di lavoro L» vengono 
analizzati generando, per ognuno di essi un 
messaggio che ne indica lo stato di attivita nella 
coda di uscita U. 

Ad ogni clock del timer T, i messaggi presenti 
nella coda di uscita U sono trasmessi al manager A 
attraverso il modulo ATX. 
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In maggior dettaglio, il modulo DC si occupa ^ =3 

2p 

esclusivamente di analizzare ogni messaggio ricevuto j< ^ 

O zj 

dal la coda di ingresso I, decomprimendolo se Z "2 

necessario, ed inviandolo, secondo priorita, ad un n2 
modulo CA fungente da coordinatore delle attivita, ^ < 

indicando altresi le modalita e la tipologia da 
attivita da svolgere . 

II modulo CA si occupa essenzialmente di : 

- istanziare un processo concorrente adatto alia 
richiesta dell' interprete di messaggi, coordinando 
le attivita attraverso un modulo controllore dei 
manager, indicato con CM, monitorandone lo stato; 

- aggiornare lo stato delle attivita delle 
richieste presenti nella coda di lavoro L, e 

- creare messaggi statistici di controllo da 
inviare al manager A nella coda di uscita U, tali 
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messaggi contenendo inf ormazioni statistiche sullo 
stato complessivo di f unzionamento dei processi 
concorrenti istanziati. 

II modulo CM si occupa di gestire in modo tanto 
coordinato quanto disgiunto ulteriori moduli 
fungenti da manager di protocollo (qui rappresentati 
a titolo di esempio in numero di tre ed indicati con 
MP1, MP2, MP3) raccogliendo ed analizzando le 
informazioni ricevute. Al termine delle attivita, il 
risultato viene inviato ad un modulo compilatore e 
compressore dei messaggi, indicato con CCM, in vista q ^ 



del successivo inserimento nella coda di uscita U ^ 

... O =i 

per xl successivo mvio al manager A. Z ^ 

II modulo CCM si occupa esclusivamente di 
gestire il risultato delle attivita prodotte dal ^ <C 

processo concorrente, creare il messaggio ed 
eventualmente comprimerlo se la richiesta e 
pervenuta in modality compressa, mettendolo nella 
coda di uscita U del gestore delle code. 

Ciascuno dei moduli denominati manager di 
protocollo MP1, MP2, MP3 (il cui numero, come gia si 
£ detto, pud essere qualsiasi, in funzione del 
numero di protocolli da gestire) si occupa di 
comunicare con gli agent attraverso uno specifico 
rispettivo protocollo (ad esempio Telnet, SNMP, 
TFTP, ecc • ) . 
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All'interno del sistema, ad ogni messaggio viene 
assegnato un numero identif icativo univoco che 
consente, in diversi moduli, di identif icarlo 
rapidamente e senza errori all' interna 

dell'architettura. Le caratteristiche 

dell'architettura dell 'agent gerarchico AG sono 
quindi riassumibili nei termini seguenti. 

L' agent gerarchico AG si configura come un 
modulo piu leggero rispetto ad un manager 
tradizionale, perche contiene semplici componenti 
che gli consentono l'emulazione dei protocolli di 
rete (ad esempio SNMP, Telnet, DNS, TFTP, ecc . ) . Ad 
esempio, nel caso del protocollo TFTP non viene 
realizzato l'intero server, ma solo le unita di base 
che rendono conforme al protocollo la comunicazione 
con gli agent. 

L' agent gerarchico AG d inoltre piu veloce 
rispetto ad un manager tradizionale, perche 
utilizza, ottimizzandola, esclusivamente la RAM del 
sistema che lo ospita senza effettuare accessi ad 
esempio verso un disco o verso base dati, accessi 
che sono notoriamente piu lenti . In piu, 1' agent 
gerarchico AG non contiene funzionalita complesse di 
elaborazione di messaggi di tipo manager e risulta 
altresi piu economico rispetto ad un manager 
tradizionale in termini di utilizzo di risorse 
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poiche e attivato solo dalla ricezione di una 
richiesta dal manager A per poi disattivarsi al 
termine dell ' attivita . 

L' architettura descritta rende possibile la 
realizzazione di attivita contemporanee e coordinate 
che coinvolgono piu tipologie di protocolli, 
offrendo altresi al manager A la possibility di 
accedere agli agent con una modalita gerarchica 
owero prevedendo che un determinate agent sia 
raggiungibile da due agent gerarchici fungenti l'uno 
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da elemento primario ed il secondo da elemento O q 
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secondario. 

Tutto questo con la possibility di utilizzare 

M O 

1' agent gerarchico secondario qualora il primo non = Z 

CO 
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sia disponibile. 

La soluzione descritta risulta quindi 
intrinsecamente piu robusta nei confront! ad eventi 
di guasto o, in generale, di indisponibilita anche 
temporanea di determinati elementi . 

La disponibilita dei moduli ARX e ATX per la 
comunicazione bidirezionale disaccoppiata permette j^^^rS^r.... 
di gestire elevati volumi di traffico in ingresso 
senza penalizzare le prestazioni di trasmissione . Initio l'f 



particolare, la gestione della trasmissione del V J im ;Emcp ' 
modulo ATX awiene secondo una modalita che pud 
essere definita tanto "temporizzata" quanto 
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"gaussiana" per blocchi di messaggi sulla base della 
rispettiva priorita. Questo modo di procedere evita 
possibili picchi di traffico perche ad ogni ciclo di 
clock viene inviato un numero predefinito di 
messaggi sulla base della priority (ad esempio venti 
di priorita tt l" , dieci di priorita w 2", otto di 
priorita w 3", due di priorita M", uno di priorita 
"5"), mentre i messaggi eccedenti rimangono in coda 
per essere inviati al ciclo successive. In piu, si 
evita la formazione di "colli di bottiglia" perche >< 
ogni messaggio fluisce da un modulo all'altro senza Oq 
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intersecarsi con gli altri attraverso buffer interni 
che disaccoppiano le velocita di esecuzione dei 

M O 

moduli . ^ ^ 

ca < 

In modo particolarmente preferito, la strut tura 
dei messaggi utilizzati per la comunicazione fra 
manager A ed agent gerarchico AG prevede, secondo le 
modalita illustrate nella figura 12, la presenza di 
un' intestazione I seguita da un corpo informativo 
CI. 

Nel caso specifico qui considerato, 
1 ' intestazione I contiene tipicamente le seguenti 
inf ormazioni : 

- versione del formato del messaggio utilizzato 
(ad esempio 1.0), 
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- tempo massimo per 1 ' esecuzione del comando (in 
millisecondi) , 

indicatore del contenuto compresso (1 
codificato, 0 = non-codif icato) , 

- descrizione dell'errore (compilato solo nei 
messaggi di conferma di assenza dell'errore oppure 
il testo dell'errore) , 

- dimensione del messaggio in byte, 

- indirizzo IP dell 'agent su cui effettuare 
1 ' attivita, 

- la priorita del messaggio indicato dal manager 
(0 = priorita assegnabile dall' agent gerarchico AG, 

I = massima, 5 = minima) , 

- identif icativo del manager di protocollo da 
utilizzare, 

- tipologia da attivita richiesta (comando vero 
e proprio) , 

porta UDP sorgente della richiesta del 
manager , 

- versione del manager A o dell 'agent gerarchico 

AG, 

identif icativo univoco della richiesta 
all'interno del manager, 

II corpo informativo CI contiene le indicazioni 
specif iche per il manager di protocollo (MP1, MP2, 
MP3, ...) da utilizzare per lo svolgimento delle 
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attivita richieste. Tali indicazioni si 
differenziano sulla base dell ' attivita da svolgere e 
del protocollo utilizzato, esprimendo ad esempi i 
seguenti contenuti : 

- procedura SNMP: contiene un messaggio SNMP 
standard con gli OID SNMP da richiedere, la 
tipologia di operazione da svolgere (GET, GET NEXT, 
SET e BULK, etc . . ) , 

- procedura Telnet: contiene i parametri per 
l'autenticazione (UID, password), i comandi ^ 
operatore, 1 ' indicazione se restituire gli output Op 
prodotti dai comandi, 

- procedura SNMP: contiene gli OID SNMP di tutti __ 

NJ O 

i rami della MIB da raccogliere attraverso la DZ 

ca < 

tipologia di operazione SNMP standard (BULK o GET 
NEXT) , 

- procedura di coordinamento : contiene, sotto 
forma di script, la modalita di coordinamento multi- 
protocollo, 

- procedura di gestione di file via TFTP (non 
standard) : contiene la tipologia di attivita upload 
oppure download, l'elenco dei file da raccogliere 
oppure i file da scaricare, 

- procedura di verifica raggiungibilita agent: 
contiene la/le tipologie di verifica da effettuare 
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DNS look-up e reverse DNS look-up, 
raggiungibilit£ porte Telnet e SNMP, 

comando di verifica raggiungibilita agent 
gerarchico: non contiene attivita da svolgere ed e 
utilizzato dal manager A per verificare la 
raggiungibilita dell 'agent gerarchico AG, e 

- comando di invio statistiche: contiene le 
inf ormazioni di registrazione e definizione della 
porta UDP del manager A a cui devono essere inviate 
le inf ormazioni statistiche. 

I comandi a loro volta possono essere compressi 
ed incapsulati utilizzando una tecnica di 
compressione algoritmica tale da prevedere 
un'operazione di compressione, in particolare basata 
sul riconoscimento di sequenze che compaiono 
periodicamente nel messaggio. 

In particolare, lo schema della figura 12 fa 
vedere come 1 ' intestazione I ed il corpo informativo 
CI del messaggio in questione possano essere 
incapsulati in una struttura di messaggio supportato 
dall' agent gerarchico AG e comprendente un header 
del messaggio MH e la parte PDU della stesso in 
vista della generazione di un messaggio SNMP o UDP /^tf* 
suscettibile di transitare sul livello IP. 

I diagrammi di flusso della figura 13 illustrano 
le modalita adottate per la compressione (figura 
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13a) e la decompressions (figura 13b) del messaggio 
SNMP. 

I diagrammi di flusso della figura 14 illustrano 
(sempre riferendosi rispettivamente alia 

trasmissione - figura 14a - ed alia ricezione - 
figura 14b) una prima soluzione che prevede il 
trasf erimento del messaggio SNMP compresso 
attraverso incapsulamento su SNMP . 

I diagrammi di flusso della figura 15 si 

riferiscono invece ad una soluzione di trasf erimento 

attraverso incapsulamento su UDP. Questo sempre con °^ ={ 

O o 

rif erimento distinto alia trasmissione (figura 15a) <Q 

P . 

ed alia ricezione (figura 15b). ^ 
Gli schemi delle figure 17 e 18 si riferiscono FfP 

Ml — 
— \ ""7 

al complesso delle operazioni di compressione e 
trasmissione esemplif icati , rispettivamente, dalla 
parte a) delle figure 13 e 14 (figura 17) e dalla 
parte a) delle figure 13 e 15 (figura 18) . 

Esaminando dapprima il diagramma di flusso della 
figura 13, il rif erimento 100 identifica la fase in 
cui l'intero messaggio SNMP (header + PDU) viene 
letto per poi essere convert ito, in una successiva 
fase indicata con 102 in formato esadecimale. Cio 
awiene applicando una codifica del tipo BER encode. 

II messaggio cosi codificato viene quindi 
compresso on-memory utilizzando una tecnica di 
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m • 

compressione basata sul riconoscimento di sequenze 
ricorsive quale ad esempio la tecnica documentata 
nella libreria zLib gia citata in precedenza, 

Cio awiene in una fase indicata con 104 cosi da 
ottenere, nella fase indicata con 106, un'unita dati 
(Data Unit) compressa e pronta per la trasmissione. 

In modo del tutto simmetrico, il diagramma di 
flusso della parte b della figura 13 comprende 
quattro fasi 206, 204, 202 e 200 (destinate ad 
essere svolte nella sequenza indicata) , in cui 
l'unita dati compressa ricevuta (fase 206) , viene 
sottoposta a decompress ione (fase 2 04) in vista 
della successiva decodifica esadecimale (fase 202) 
con successiva ricostruzione dell'interno messaggio 
SNMP (fase 200) . 

II fatto di aver attribuito alle fasi del 
diagramma di flusso della parte b) della figura 13 
riferimenti numerici ordinati in modo inverso 
rispetto alia loro sequenza di attuazione e 
destinato unicamente a mettere in luce il carattere 
di simmetria con le fasi 100 a 106 del procedimento 
di compressione. Analoghe scelte sono state fatte 
con riferimento ai diagrammi di flusso della figura 
14 e della figura 15. 

Come gia indicato, la figura 14 e la figura 17 
si riferiscono ad una soluzione di trasf erimento che 
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prevede 1 ' incapsulamento dell'unita dati compressa 
in un messaggio SNMP standard caratterizzato da un 
Variable Binding con invio in modalita standard su 
UDP. 

La metodologia di incapsulamento della Data Unit 
compressa ottenuta nella fase 106 prevede in una 
fase iniziale, indicata con 108, che l'unita dati 
compressa venga letta in byte per poi essere 
trasposta, in una successiva fase di codifica 
indicata con 110, nel corrispettivo insieme di 
caratteri ASCII. 



06 



X 



Nella successiva fase indicata con 112 Q o 

( event ualmente preceduta da funzioni ausiliarie 
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quali ACK TAB + NULL - si veda il blocco 110a della 

nO 

figura 17) viene generato il "Variable Binding" del Z 
messaggio costituito da un primo OID con una 
numerazione (ad esempio 1.3.6.1.4.666.1) che 
contiene nel suo valore la stringa __ZIP_xxxx, dove 
xxxx rappresenta la dimensione del file originale. 
Nell 'esempio sopra citato e stato indicato il codice 
proprietario 666.1 che - al momento - non risulta 
registrato presso la I ANA - Internet Assigned 
Numbers Authority. 

I successivi ' elementi del Variable Binding che 
contengono l'unita dati compressa tradotta in ASCII 
sono costituiti da coppie OID/valore. Il valore 
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contiene porzioni dell'unita dati compressa e 
trasposta in ASCII della dimensione massima di 255 
caratteri . 

Vengono quindi ricostruite le inf ormazioni di 
header del messaggio SNMP. Tut to cio awiene nella 
fase 112, che e seguita da una fase indicata con 114 
in cui si realizza un'ulteriore codifica secondo la 
metodologia BER mirante a generare il carico utile 
(payload) della PDU UDP destinato ad essere 
impiegato per l'invio dei dati (fase 116). 

Anche in questo caso, le fasi indicate con 216, 
214, 212, 210 e 208 riprodotte nella parte b) della 
figura 14 e destinate ad essere attuate nell'ordine 
in cui sono state citate in precedenza, 
rappresentano le funzioni duali - destinate ad 
essere attuate in ricezione - delle fasi 108 a 116 
relative all ' operazione di trasmissione . 

Adottando la soluzione a cui si riferiscono le 
figure 14 e 17, il messaggio SNMP compresso ha 
quindi un formato logico SNMP standard, ma un 
contenuto proprietario . Esso richiede quindi 
un' estensione funzionale - peraltro minimale - del 
manager dell 'agent tale da consentire 
riconoscimento e la codif ica/decodif ica. 
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Le esperienze condotte dalla Richiedente 
dimostrano che tale soluzione e del tutto fattibile 
senza incidenza negativa sull ' architettura di rete . 

La soluzione alternativa a cui fanno rif erimento 
le figure 15 e 18 prevede la preparazione dell 'unita 
dati compressa a partire dal messaggio SNMP secondo 
le modalita illustrate nella figura 13 seguita dal 
diretto incapsulamento di tale unita dati nel carico 
utile del la PDU UDP . 

Naturalmente , per funzionare correttamente, 
questa soluzione richiede la disponibilita di un _ ^ 

trasmettitore e di un ricevitore dedicati (quali ad <C ° 

esempio l moduli ARX ed ATX delle figure 9 e 11) , ad 2: ^ 

esempio in condizioni che prevedono la disponibilita m 2 

di una porta UDP diversa da quella standard. II 
trasmettitore deve quindi conoscere la porta UDP 
utilizzata dal ricevitore e viceversa. Le 
informazioni sulle porte utilizzate possono essere 
scambiate, a livello superiore, utilizzando un 
messaggio di sincronizzazione in formato SNMP 
standard secondo i criteri meglio illustrati nel 
seguito . 

Adottando la soluzione alternativa illustrata 
nelle figure 15 e 18, 1' unita dati compressa resa 
disponibile nella fase 108 e destinata a sostituire 
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il BER del messaggio - diventa il carico utile del 
messaggio UDP. 

La relativa operazione e schematizzata dalla 
fase indicata con 120 nelle figure 15 e 18, fase che 
precede la fase di trasmissione 122 destinata alia 
rispettiva porta dedicata (denominata in generale 
porta X) del ricevitore. 

Anche in questo caso, 1' operazione complement are 

si articola su tre fasi indicate rispettivamente con 

222 (ricezione sulla porta Y del modulo che al 

momento funge da ricevitore) , 220 (estrazione del 06 

carxco utile della PDU UDP) e 218 (ottenimento <q 

^ — _• 

dell'unita dati compressa ricevuta destinata ad § erf % 

essere trasferita verso la fase 206 del diagramma di £jO 
flusso della parte b della figura 13) . ^< 

Anche in questo caso le fasi 222, 220 e 218 
vengono svolte nell'ordine con cui sono state 
citate . 

II messaggio di sincronizzazione a cui si faceva 
riferimento in precedenza e inviato dal manager A 
all 'agent gerarchico AG secondo un generale criterio 
applicazione-per-applicazione (application-to- 
application) utilizzando il formato SNMP standard 
contenente un Variable Binding proprietario . 

Le informazioni trasferite possono essere del 

tipo 



OID 



Value 



1.3.6.1.4.666,2 


<UDP JTX_Por t > 


1.3 .6.1.4.666.3 


<UDP_RX_Port> 



II manager A invia all 'agent gerarchico AG un 
messaggio proprietario compilando il valore 
<UDP_TX_Port> con il numero della porta destinata ad 
essere utilizzata per la trasmissione UDP (ad 
esempio 1024) nonche un valore <UDP_RX_Port> con il 
numero della porta che utilizzera per la ricezione 
UDP (ad esempio 1224) . L' agent gerarchico AG 
risponde al manager A con un messaggio analogo ma 
contenente le proprie inf ormazioni . Questo metodo 
riduce il tempo di elaborazione migliorando 
1 ' ef ficienza della soluzione. 

Lo schema a blocchi della figura 16 fa 
ulteriormente vedere come la soluzione descritta 
possa essere generalizzata cosi da poter essere 
applicata a qualunque tipologia di messaggio che 
utilizza UDP come trasporto (ad esempio SNMP, PING, 
ecc). Tale generalizzazione consente di realizzare 
un driver UDP in grado di sostituire quelli 
attualmente utilizzati. 

Questa soluzione prevede di valutare la 
dimensione del carico utile da trasferire procedendo 
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quindi, se le dimensioni risultano opportune (ad 
esempio, maggiore di 20 byte) , utilizzando il metodo 
descritto. Al fine di dichiarare al ricevente la 
natura compatta del messaggio UDP si possono 
utilizzare gli 8 bit compresi dal bit 62 al bit 69 
dell 'header del messaggio UDP (attualmente tali bit 
non vengono utilizzati e sono posti di default a 
valore 0) ponendo a 1 ad esempio uno i piu di tali 
bit. 

In particolare, nello schema della figura 16 il 
riferimento 3 00 indica una qualunque fase in cui si 
generi 1 ' esigenza di inviare un messaggio 
suscettibile di essere trasportato su UDP seguito da 
una fase 3 02 di compressione del carico utile, 
attuato secondo le modalita descritte in precedenza. 

Una successiva fase 3 04 prevede la generazione 
dell 'header del messaggio UDP nei termini richiamati 
in precedenza, mentre una successiva fase indicata 
con 3 06 corrisponde alia creazione del messaggio UDP 
complete in vista della sua trasmissione IP, attuata 
in una fase indicata con 308, 

Naturalmente, fermo restando il principio 
dell' invenzione, i particolari di realizzazione e le 
forme di attuazione potranno essere ampiamente 
variati rispetto a quanto descritto ed illustrato, 
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senza per questo uscire dall f ambito clella presente 
invenzione. 
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RIVENDICAZIONI 

1. Procedimento per realizzare, a partire da 
almeno un oggetto gestore (A), un' attivita di 
gestione di almeno un oggetto gestito (Bl, . BN) 
tramite almeno una rete telematica (R) , 
caratterizzato dal fatto che comprende le operazioni 
di: 

- prowedere almeno un oggetto intermedio (AG) 
configurato per realizzare su detto almeno un 
oggetto gestito (Bl, . .., BN) detta attivita di 
gestione in funzione di un insieme di inf ormazioni ^ x 

(1100) detta attivita di gestione traducendosi in un §P 



P 



insieme di risultati (1104) , 

- fornire detto insieme di inf ormazioni (110 0) a * — 

M O 
hsi I — 

partire da detto almeno un oggetto gestore (A) verso g> Z 

detto oggetto intermedio (AG) , 

- svolgere detta attivita di gestione di detto 
almeno un oggetto gestito (Bl, Bn) tramite 
detto almeno un oggetto intermedio (AG) , cosi da 
generare detto insieme di risultati (1104), 

- trasferire (1108) detto insieme di risultati 
(1104) da detto almeno un oggetto intermedio (AG) 
verso detto almeno un oggetto gestore (A) . 

2. Procedimento secondo la rivendicazione 1, 
caratterizzato dal fatto che comprende 1'operazione 
di realizzare la comunicazione fra detto almeno un 
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oggetto gestore (A) e cietto almeno un oggetto 
intermedio tramite protocollo UDP. 

3 . Procedimento secondo la rivendicazione 1 o la 
rivendicazione 2, caratterizzato dal fatto che 
comprende le operazioni di : 

realizzare detta attivita di gestione su 
almeno un primo oggetto gestito (Bk, . . . , BN) 
direttamente tramite detto almeno un oggetto gestore 
(A) , 

realizzare dette attivita di gestione su 
almeno un secondo oggetto gestito (Bl, B2, B3) a 
partire da detto almeno un oggetto gestore (A) 
tramite detto oggetto intermedio (AG) . 

4. Procedimento secondo la rivendicazione 3, 
caratterizzato dal fatto che comprende 1'operazione 
di realizzare la gestione di detto almeno un primo 
oggetto gestito (Bk, . . . , Bn) e di detto almeno un 
secondo oggetto gestito (Bl, B2, B3) tramite 
un'unica rete telematica (R) . 

5. Procedimento secondo la rivendicazione 3, 
caratterizzato dal fatto che comprende le operazioni 
di: 

- prowedere una prima rete telematica (RP) per 
realizzare la gestione di detto almeno un primo 
oggetto gestito (Bl) direttamente tramite detto 
almeno un oggetto gestore (A) nonche il 
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trasf erimento di detto insieme di inf ormazioni 
(1100) e di detto insieme di risultati (1108) fra 
detto almeno un oggetto gestore (A) e detto almeno 
un oggetto intermedio (AG) , e 

- prowedere una seconda rete telernatica (RA) 
per realizzare detta attivita di gestione di detto 
almeno un secondo oggetto gestito (B2 , B3) tramite 
detto oggetto intermedio (AG) . 

6. Procedimento secondo una qualsiasi delle 
rivendicazioni precedents caratterizzato dal fatto 
che comprende le operazioni di prowedere una 
pluralita di detti oggetti intermedi (AG1, AG2) e di 
realizzare la gestione di almeno un oggetto gestito 
(B3) tramite piu oggetti intermedi (AG1, AG2) di 
detta pluralita. 

7. Procedimento secondo una qualsiasi delle 
precedenti rivendicazioni, caratterizzato dal fatto 
che detto oggetto intermedio (AG) e prowisto di 
rispettivi moduli di ricezione (ARX) e di 
trasmissione (ATX) configurati in modo tale per cui 
detto almeno un oggetto gestore (A) vede detto 
oggetto intermedio (AG) sostanziamente come un detto 
oggetto gestito (Bl, . . . , Bn) . 

8. Procedimento secondo una qualsiasi delle 
precedenti rivendicazioni, caratterizzato dal fatto 
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che detto almeno 



un oggetto intermedio (AG) 
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comprende almeno un rispettivo modulo di gestione 
(MM) configurato in modo tale per cui detto almeno 
un oggetto gestito (Bl, BN) su cui detta 

attivita di gestione viene realizzata tramite detto 
almeno un oggetto intermedio (AG) vede detto almeno 
un oggetto intermedio (AG) sostanzialmente come 
detto almeno un oggetto gestore (A) . 

9. Procedimento secondo una qualsiasi delle 

precedenti rivendicazioni , caratterizzato dal fatto 

che comprende l'operazione di prowedere, in detto 

almeno un oggetto intermedio (AG) , una coda scelta 06 ^ 

O o 

nell'insieme costituito da: <^C± 

. 

- una coda di ingresso (I) in cui sono raccolti 8 3 " 
messaggi in ingresso rispetto a detto almeno un N O 
oggetto intermedio (AG) , ^ < 

- una coda di uscita (U) in cui sono raccolti 
messaggi in uscita da detto almeno un oggetto 
intermedio (AG) , e 

- una coda di lavoro (L) in cui sono raccolti 
messaggi inerenti a detta attivita di gestione 
svolta da detto almeno un oggetto intermedio (AG) su 
detto almeno un oggetto gestito (Bl, . .., Bn) . 

10. Procedimento secondo la rivendicazione 9, 
caratterizzato dal fatto che comprende l'operazione 
di prowedere, in detto almeno un oggetto intermedio 
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(AG) , un modulo (DC) dedicato ad analizzare i 
messaggi ricevuti su detta coda di ingresso (I) . 

11. Procedimento secondo la rivendicazione 9 o 
la rivendicazione 10, caratterizzato dal fatto che 
comprende le operazioni di : 

prowedere, in detto almeno un oggetto 
intermedio (AG) , un modulo di coordinamento delle 
attivita (CA) per realizzare almeno una funzione 
scelta nel gruppo costituito da: 

- istanziare almeno un processo concorrente, 

- aggiomare lo stato delle attivita delle $ 5 

rxchieste presenti in detta coda di lavoro (L) , e ^ _ 

Or! u 

- creare messaggi statistici di controllo da Z =? ** 
inviare a detto almeno un oggetto gestore (A) § 
tramite detta coda di uscita (U) . 

12. Procedimento secondo una qualsiasi delle 
precedenti rivendicazioni , caratterizzato dal fatto 
che comprende l'operazione di prowedere in detto 
almeno un oggetto intermedio (AG) una plurality di 
moduli di gestione di protocollo (MPl, MP2, MP3) 
configurati per realizzare la comunicazione verso 
detto almeno un oggetto gestito (Bl, BN) 
tramite rispettivi protocolli di tipo diverse 

13. Procedimento secondo una qualsiasi delle 
precedenti rivendicazioni, caratterizzato dal fatto 
che comprende l'operazione di realizzare la 
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comunicazione fra detto almeno un oggetto gestore 
(A) e detto almeno un oggetto intermedio (AG) 
sottoponendo almeno parte dei relativi messaggi ad 
un' operazione di compressione (302; 104, 204). 

14. Procedimento secondo la rivendicazione 13, 
caratterizzato dal fatto che detta operazione di 
compressione d basata sul riconoscimento di sequenze 
che compaiono periodicamente nel messaggio. 

15. Procedimento secondo la rivendicazione 14, 
caratterizzato dal fatto che detta operazione di 



caratterizzato dal fatto che comprende 1' operazione 
di indicare l'awenuta compressione nel messaggio 
trasferito tramite UDP. 

17. Procedimento secondo la rivendicazione 16, 
caratterizzato dal fatto che per indicare 1 ' awenuta 
operazione di compressione (3 02) viene utilizzato un 
campo di bit dell 'header UDP. 

18. Procedimento secondo la rivendicazione 17, 
caratterizzato dal fatto che per indicare l'awenuta 
operazione di compressione (3 02) vengono utilizzati 
i bit compresi dal bit 62 al bit 69 dell 'header 
UDP. 
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compressione viene svolta secondo una tecnica di O o 

on ^ 

tipo gzip quale zLib. ^ . 

O ri~ 

16 . Procedimento secondo la rivendicazione 2 ed Z ^ ^> 

una qualsiasi delle rivendicazioni 13 a 15, !z! Z 
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19. Procedimento secondo la rivendicazione 18 , 
caratterizzato dal fatto che comprende 1' operazione 
di porre ad 1 almeno uno fra i bit 62 a 69 
dell 'header del messaggio UDP. 

20. Procedimento secondo una qualsiasi delle 
rivendicazioni 13 a 19, caratterizzato dal fatto che 
la comunicazione fra detto almeno un oggetto gestore 
(A) e detto almeno un oggetto intermedio (AG) si 
realizza tramite messaggi SNMP, il procedimento 
comprendendo, in fase di compressione, le operazioni 
di: 

- leggere (100) l'intero messaggio SNMP, 

- codificare (102) il messaggio letto in formato 
esadecimale , e 

- sottoporre il messaggio codificato in forma 
esadecimale all ' operazione di compressione (104) . 

21. Procedimento secondo una qualsiasi delle 
rivendicazioni 13 a 19, caratterizzato dal fatto che 
la comunicazione fra detto almeno un oggetto gestore 
(A) e detto almeno un oggetto intermedio (AG) si 
realizza tramite messaggi SNMP, il procedimento 
comprendendo, in fase di ricezione, le operazioni 
di: 

sottoporre il messaggio ricevuto • ad 
un 7 operazione di de- compressione (204) complementare 
a detta operazione di compressione/ cosi da 
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ottenere un messaggio sottoposto a decompressione in 
formato esadecimale, 

- decodificare (2 02) il messaggio sottoposto a 
de-compressione (204) a partire dal formato 
esodecimale, e 

ricostruire (200) l'intero messaggio SNMP a 
partire dal messaggio decodificato a partire dal 
formato esadecimale. 

22. Procedimento secondo la rivendicazione 2 0 o 

la rivendicazione 21, caratterizzato dal fatto che 

comprende 1' operazione di incapsulare ai fini del °S =j 

O o 

trasf erimento il messaggio sottoposto a detta ^ q 



operazione di compressione (104) in un messaggio § erf 
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SNMP standard. M O 

23. Procedimento secondo la rivendicazione 22, 00 < 

caratterizzato dal fatto che , in sede di 
trasmissione, comprende le operazioni di : 

- leggere (108) il messaggio sottoposto a detta 
operazione di compressione (104) in byte, 
trasponendolo (110) in un corrispondente messaggio 
in caratteri ASCII, 

- generare (112) un insieme di variable binding 
comprendente un primo OID indicativo della 
dimensione del file originale e successive coppie 
OID/valore che veicolano porzioni di detto messaggio 



-SO- 



sottoposto a detta operazione di compressione (104) 
trasposto in carat teri ASCII, 

ricostruire le inf ormazioni di header del 
messaggio SNMP, 

codificare (114) il messaggio SNP cosi 
ottenuto in formato esadecimale cosi da generare 
carico utile UDP, e 

- trasferire (116) il carico utile cosi generato 
tramite UDP. 

24. Procedimento secondo la rivendicazione 22 o 
la rivendicazione 23 , caratterizzato dal fatto che, 



operazione di compressione come carico utile UDP 
(216) , 

sottoporre il carico utile cosi ricevuto ad 
un' operazione di decodifica esadecimale (214), 

riconoscere ed assemblare (212) il variable 
binding del messaggio sottoposto a decodifica 
esodecimale, 

sottoporre il messaggio sottoposto a detta 
operazione di riconoscimento ed assemblaggio (212) 
ad un' operazione di decodifica da ASCII a binario 
(210) , e 

- sottoporre il messaggio decodificato in forma 
binaria a detta operazione di de- compressione (204) . 
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in sede di ricezione, comprende le operazioni di : < ^ 

o 3^ 

ricevere il messaggio sottoposto a detta z \£± •» 
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25. Procedimento secondo la rivendicazione 20 o 
la rivendicazione 21, caratterizzato dal fatto che 
comprende 1' operazione di integrare il messaggio 
sottoposto a detta operazione di compressione (104) 
tramite incapsulamento su UDP. 

26. Procedimento secondo la rivendicazione 25, 
caratterizzato dal fatto che, in fase di 
trasmissione, comprende le operazioni di : 

- configurare detto messaggio sottoposto a detta 
operazione di compressione (104) come carico utile 
di Protocol Data Unit (PDU) , e o ?R 

- trasferire il carico utile cosi creato verso 
una porta data di un ricevitore. 
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27. Procedimento secondo la rivendicazione 25 o id Z 
la rivendicazione 26, caratterizzato dal fatto che, 
in sede di ricezione, comprende le operazioni di : 

- ricevere detto messaggio come carico utile di 
una PDU UDP ricevuta su una porta di ricevitore, e 

- estrarre detto carico utile da detta PDU. 

28. Procedimento secondo la rivendicazione 2 6 o 
la rivendicazione 27, caratterizzato dal fatto che 
comprende 1' operazione di trasmettere fra detto 
almeno un oggetto gestore (A) e detto almeno un 
oggetto intermedio (AG) un messaggio di 
sincronizzazione (1106) di tipo SNMP identif icativo 
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di detta porta di trasmissione e/o di detta porta di 
ricezione . 

29. Sistema per la gestione di reti telematiche 
comprendente almeno un oggetto gestore (A) ed almeno 
un oggetto gestito (Bl, . . . , Bn) , carat terizzato dal 
f atto che comprende almeno un oggetto intermedio 
(AG) operante in base al procedimento secondo una 
qualsiasi delle rivendicazioni 1 a 28. 

30. Prodotto informatico dire tt amen te caricabile 
nella memoria interna di un elaboratore numerico e 
comprendente porzioni di codice software per 
attuare il procedimento secondo una qualsiasi delle 
rivendicazioni 1 a 28 quando il prodotto viene fatto 
girare su un elaboratore numerico. i 
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